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Glossary 

1. Introduction 

This document defines the terminology specific to the POST Tools Project, explaining terms which may be 
unfamiliar to the reader of the use-case descriptions or other project documents. The reader may use this 
document as an informal data dictionary, capturing data definitions so that use-case descriptions and other 
project documents can focus on what the system must do with the information. 

2. Definitions 

For easier contextual reference we list the terms and definitions by tool. The following subsections contain 
the general terms, then the terms for the Command and Data Tool, Mission Operations Tool, Shared Data 
Repository Tool, MCC Display Tool, Orbiter-in-a-Box Tool, and SMS Model Tool. 

2.1 General 

The section contains the terms and definitions that apply to all of the components of the POST Tools 
project. Terms and definitions for specific products within the POST Tools project are found in the 
following sections. 

2.1.1 Cargo PC 

Cargo Personal Computer. The Cargo PC is a laptop computer (IBM ThinkPad) that runs the payload 
flight software on-board the orbiter. A Cargo PC in the "mode A" configuration includes a MIC and a 
PCMMU interface card. The MIC provides a command interface with the GPCF through the special MDM 
serial I/O card. The PCMMU interface enables the Cargo PC to read orbiter telemetry and state 
information directly from the PCMMU. One or more Cargo PC's in the "mode B" configuration operate as 
a clients of a "mode A" Cargo PC server; these communicate via Ethernet. The payload flight software 
runs on the Cargo PC. To perform any hazardous commands, however, the Cargo PC software must issue 
the appropriate command request to the GPCF. 

2.1.2 CDR 

Critical Design Review. The CDR is a technical review to ensure that the system detailed design and 
testing plan is traceable to functional requirements and non-functional requirements. In the POST Tools 
Project we combine the CDR with the PDR. Completion of the CDR requires detailed design 
specifications, traceability of design to requirements, preliminary test plans, and preliminary deployment 
plans. 

2.1.3 CDT 

Command and Data Tool. See 2.2. 

2.1.4 GNC 

Guidance, Navigation and Control. This is one major function of the PASS. Many of the orbiter 
subsystems interact with the GNC major function; however, this interaction does not include the payload 
functions. 

2.1.5 GPC 

General Purpose Computer. This is the label for the five Space Shuttle on-board flight computers. These 
computers run the Primary Avionics System Software (PASS) or Backup Flight System (BFS) flight 
software. 
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2.1.6 GPC Emulator 

General Purpose Computer Emulator. The GPC emulator is a C++ program that serves as a GPC virtual 
machine. The emulator enables us to load and execute the orbiter flight software into the virtual machine 
running on a Unix workstation. The emulator models the registers, addressing modes and instruction set of 
the real GPC. Many emulator components and services model the GPC peripherals and related data 
processing subsystem elements. The GPC emulator is the distinguishing function of the orbiter-in-a-box. 

2.1.7 MOT 

MCC Display Tool. See 2.5. 

2.1.8 Mission Operators 

The mission operators are the recipients of the payload customer's products. They acquire the products 
from the POST and from the shared data repository. 

2.1.9 MOT 

Mission Operations Tool. See 2.3. 

2.1.10 OiaB 
Orbiter-in-a-Box. See 2.6. 

2.1.11 ORR 

Operational Readiness Review. The ORR is a technical review of requirements, test results, deployment 
plans, and support plans to determine whether the products are ready for operational use. A positive 
outcome states that we can trace test results to requirements and that the products are ready for operational 
use. 

2.1.12 PASS 

Primary Avionics System Software. This is the primary orbiter on-board software system. The various 
POST tools assume integration only with the PASS (not with the Backup Flight System software). 

2.1.13 Payload Customer 

The payload customer is the primary user of the POST tools. The payload customer employs the tools to 
produce the command, data, training and documentation products required to support his payload's flight. 

2.1.14 POST Field Engineer 

The field engineer is a member of the POST specializing in installation, configuration, and operation of the 
POST tools. The POST field engineer will train the customer on the use of the tools and will provide on- 
going mentoring. 

2.1.15 PDR 

Preliminary Design Review. The PDR is a technical review to ensure that the system design is traceable to 
functional requirements. The review also examines interface definitions and requirements. Successful 
accomplishment of the PDR requires design specifications, traceability of design components to functional 
requirements (use cases), and definition of interface control documents (if applicable). In the POST Tools 
Project we combine the PDR with the CDR. 

2.1.16 SDR 

Shared Data Repository. See 2.4. 
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2.1.17 SM 

System Management. This is one major function of the PASS. Prior to 01-29 the SM contained the 
payload software. The GPCF is part of the SM major function. 



2.1.18 SMT 

SMS Model Tool. See 2.7. 



2.1.19 System Administrator 

The POST tools system administrators are the tools super-user. The system administrators configure the 
tools and network to support POST and customer use of the tools in the field. The system administrator 
also manages the shared host repository. 

2.1.20 SRR 

Systems Requirements Review. The SRR is a technical review to ensure that we have identified a 
complete set of detailed requirements and that we have obtained stakeholder agreement. Completion of the 
SRR requires a common understanding of top-level requirements and an approach for specifying and 
tracking these requirements. We also identify traceability for reinventiorf^verall requirements. 

2.1.21 TRR 

Test Readiness Review. The TRR is a technical review of the plans for demonstrating during acceptance 
testing that the products meet requirements. Completion of the TRR requires definition of acceptance 
testing plans, traceability of tests to requirements, and documentation of testing components and 
procedures. 

2.2 Command and Data Tool 

This section contains the terms and definitions specific to the Command and Data Tool product. 

2.2.1 Baselined Data 

Baseline data refers to the process of approving the changes made to payload data. This refers to data that 
has completed the data life cycle. Within the data category, the data can eventually be purged, but it cannot 
be changed. See data life cycle. 



2.2.2 Command Table 

The GPCF provides each payload application with a command table for up to 15 commands. These are 
PSP and MDM commands (see Orbiter-in-a-Box). Each command has a 20-character text field serving as 
its description to the crew on the GPCF PL Commanding SPEC (SPEC 72). 

2.2.3 Data Category 

The data category is a group of data elements that define a specific type of data. Examples of these groups 
are Basic Command Measurement, Calibration, Command, Channelization, Downlist, and FDA. 
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2.2.4 Data Life Cycle 

Progression of required states that data follows from collection to baselining. The valid states are working, 
locked, baselined. Working is a state where data is currently being updated. Locked is the state where data 
cannot be updated unless unlocked. Baselined is the final state of the data life cycle. In this state data 
cannot be changed. The working and locked states may be repeated as many times as needed. The valid 
changes in status are defined as follows: 

(1) create data (working), 

(2) from a working to a locked state; the process is called lock, 

(3) from a locked to a working state; the process is called unlock, 

(4) from a locked to a baselined state; the process is called baseline 

2.2.5 Data Table 

The GPCF enables a total of 200 discrete and 100 analog items in a payload data monitoring data table. 
Some of this content can be defined as late as on-orbit. The GPCF provides each payload application with 
up to 30 discrete and 5 analog feedbacks. The GPCF PL Data SPEC (SPEC 73) shows all feedbacks when 
the crew selects the payload application as primary. A secondary payload's feedbacks can consume any 
remaining space on the display. ^ w 

2.2.6 Delta-Delta Report 

A single report or a set of reports that display the incremental changes made to any payload items since the 
last update of these items. This function should also reflect the changes made between two non- 
consecutive versions of the same product. 

2.2.7 Global Change 

This term refers to the ability of the CDT to reflect all changes made to certain OI parameters (e.g., 
payload ID or PDI port assignment). 

2.2.8 GPCF 

GPC Payload Command Filter. The GPCF is an orbiter SM flight software application that provides for 
integrating most payload applications into orbiter flight software without requiring flight-to- flight 
reconfiguration. This function enables a Cargo PC to issue hazardous commands to a payload, while the 
GPC provides critical data monitoring and fault detection and annunciation. Moreover, the GPCF provides 
for a generic hazardous and critical command backup capability. The GPCF function is new in OI-29. 

2.2.9 Hazardous Commands 

In the GPCF context, hazardous commands are those command table items that are PSP commands. 
Hazardous commands must be identified as such, and the GPCF loads them in an inhibited/safed status. 
(The GPCF loads other commands as enabled.) A command must be in the enabled status before the GPCF 
will issue the command. 

2.2.10 MSID 

Measurement Stimulus Identification. Identification number that is unique for each orbiter or payload 
related measurement (identifies signal source) or stimulus (identifies signal destination). 

2.2.11 OI 

Operational Increment. This term refers to the version of the flight software. The OI-29 version is the first 
to contain the GPCF and therefore includes support for the Cargo PC. 
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2.2. 12 Reconfiguration 

Reconfiguration refers to the process of configuring the Cargo PC, Flight Software, Orbiter-in-a-Box, or 
SMS model for a specific mission or mission context. 



2.2. 13 Shuttle Data Integration Plan 

The Shuttle DIP document is data element dictionary for the Data Management System presently known as 
Measurement and Stimulus (MAST) II and Space Transportation Automated Reconfiguration (STAR). It 
documents configuration of the MAST II and STAR deliverable product formats. 

2.2.14 SPFOPD 

The Software Production Facility (SPF) Operations Planning Document (OPD) contains Level B 
Application Software Requirements that establish a set of detailed design, coding, and testing for the 
following: 

® on-line interactive process that supports a user's access, update, and management of data 
® defined data structures and the processes that interface with these structures 
o offline batch process (reports, audits, integration, and product generation) 
• configuration management processes 

2.2.15 STAR 

Space Transportation Automated Reconfiguration (STAR) is an operational reconfiguration system which 
provides configuration control and validation of payload related measurement data values used to 
reconfigure flight software. It is used to collect information about a particular shuttle mission's payload 
configuration. It is based on IMS databases and uses ADF based screens from 3270 type devices (often PCs 
running emulation software). Data produced by the STAR system is also fed into the MAST system. 

2.2.16 STAR PC 

STAR PC is an offline data entry program for payload reconfiguration data. It is written in Turbo Pascal 
and runs as a DOS character mode program on IBM PC's. STAR/PC builds data files that are mailed to the 
SPF on diskettes. SPF personnel upload the diskette data file to MVS using the TSO file transfer utilities in 
the 3270 emulation software. 



2.2.17 Wizard 

An interactive utility that guides the user through a potentially complex task. Wizards are often 
implemented as a sequence of dialog boxes which the user can move forwards and backwards through, 
filling in the details required. The implication is that the expertise of a human wizard in one of the above 
senses is encapsulated in the software wizard, allowing the average user to perform expertly. 

2.3 Mission Operations Tool 

This section contains the terms and definitions specific to the Mission Operations Tool product. 

2.3.1 BAT 

Baseline Assessment Team. This USA team performs optimization analyses that support flight 
manifesting decisions prior to FDRD baselining. These analyses provide early examination of 
consumables, mass properties, ascent performance margin, and launch window. The BAT is a cooperative 
effort between the USA Program Integration and Flight Operations Offices. 

2.3.2 CIP 

Cargo Integration Plan. TBS. 
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2.3.3 CITE 

Cargo Integration Test Equipment. CITE is a set of test facilities at KSC that provide for functional 
checkout of Space Shuttle payloads prior to them being integrated into the orbiter payload bay. CITE 
provides both copper-path and end-to-end test capabilities. 



2.3.4 Consumables 

Payload-specific requirements for electrical power, thermal management, or other energy sources. 

2.3.5 FAWG 

Flight Assignment Working Group. TBS. 

2.3.6 FDRD 

Flight Definition and Requirements Directive. TBS. 

2.3.7 Flight Data File 

The Flight Data File refers to the collection of published procedures, checklists, and supporting 
documentation that the crew uses on-board and the flight control team uses in the MCC. 

2.3.8 Flight Rules Annex 

The Annex is a flight- specific addition to the generic Flight Rules document. The Annex contains rules 
and policies governing the operation and control of payloads and tests. 

2.3.9 FRD 

Flight Requirements Document. The FRD is an integrated collection of high-level requirements that apply 
to the entire flight, crossing boundaries that apply to individual payloads or experiments. The FRD does 
not approach the level of detail found in the PIPs for the individual payloads. 

2.3.10 FTSOD 

Flight Test and Supplementary Objectives Document. TBS. 

2.3.11 HMST 

Hazardous Materials Summary Table. TBS. 

2.3.12 ICA 

Integrated Cargo Assessment. TBS. 

2.3.13 ICD 

Interface Control Document. The ICD controls the arrangement and nature of the interfaces between a 
payload element and the orbiter. It is subservient to the PIP. 

2.3.14 OMRS 

Orbiter Maintenance Requirements Specification. The OMRS collects the requirements pertaining to Space 
Shuttle ground processing. This document collects most mission-unique payload ground processing 
procedure requirements. 

2.3.15 PIP 

Payload Integration Plan. The PIP is the primary requirements collection document for a single payload. 
The PIP and its annexes contain detailed payload integration requirements. 
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2.3. 16 TDDP 

Trajectory Design Data Package. The TDDP is a fundamental input for both USA Ascent Flight Design and 
Spaceflight Systems Propulsion Analysis groups. It contains detailed hardware mass properties and crucial 
parameters for the purposes of detailed mass properties analysis and ascent trajectory design. 



2.4 Shared Data Repository Tool 

This section contains the terms and definitions specific to the Shared Data Repository (SDR) Tool. 

2.4. 1 Check-In 

Check-in refers to the process of uploading a new version of a data unit from a working data store to a 
control data store. A user cannot check-in an item for which he does not own a lock. If the user requests 
that his lock be yielded, then the CM system also considers the item unlocked such that another user may 
then request a check-out with lock to make revisions. 

2.4.2 Check-Out 

Check-out refers to the process of downloading a version of a data unit from a control data store to a 
working data store. If the user requests a lock then the CM system considers the item reserved such that 
only the lock owner can perform modifications on the item, thereby excluding changes by any other party. 

2.4.3 CM 

Configuration Management. This refers to the policies and processes by which we ensure the integrity and 
traceability of critical products. 

2.4.4 CM API 

Configuration Management Application Programming Interface. The CM API is a standardized software 
interface into the SDR CM system. This API enables computer programs to perform CM tasks such as 
check-in and check-out. 

2.4.5 Data Unit 

A data unit is the atomic level representation of a configuration-managed item. This is the smallest unit of 
representation in the CM system. Records may consist of many data units, but a data unit may not be split 
across CM versions or repositories. 

2.4.6 Export 

An export action refers to the process of translating an SDR product into some external data representation. 
This action typically occurs to make the product importable by a foreign tool. 

2.4.7 Import 

An import action refers to the process of translating some external data representation into a format that the 
SDR understands. This action typically occurs to make a foreign product usable by the SDR, and usually 
occurs only during initialization of a product or data set. 

2.4.8 Lock 

The SDR uses the noun lock to indicate that a user has write privilege reserved for a data unit. The user 
acquires this privilege during a check-out action. Once acquired, the user preserves the lock until he 
specifically yields the lock, which might occur in combination with a check-in action. 
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2.4.9 BDS 



Baseline Data Store. The BDS contains the baselined data units for access by consumers. There is a BDS 
for each payload. The BDS resides at the central SDR site, not at the customer remote site. Data units 
enter the BDS only via promote action from a CDS. 



Control Data Store. The CDS may be thought of as a working version of the BDS. Users perform check-in 
and check-out actions through the CDS to their working data stores. The CDS contains the latest versions 
of all data units under development. When data units reach maturity users promote them to the BDS. Each 
CDS resides at the central SDR site, and there is one CDS for each payload. Editing and other 
manipulation of the data units is not performed at the CDS: this must be performed at a WDS. 

2.4.11 POST Control Store 

The POST control store is a special database for the system administrator. Here is where we maintain 
account information and other private data for the entire POST community. 

2.4.12 POST Master Schema ~~ 

The POST master schema is the default data set and configuration for an SDR site initialization. When the 
system administrator initializes a new site, the SDR tools employ the master schema to initialize the site's 
BDS and CDS. 

2.4.13 Promote 

A promote action refers to the process of migrating data units from the CDS to the BDS. A promote action 
also carries some traceability information that establishes a baseline version for a data unit. We do not 
provide a corresponding demote action. 

2.4.14 Subsystem 

An SDR subsystem refers to a collection of units generally associated with a particular tool. For instance, 
we would consider the data units associated with the CDT as a subsystem. This term is primarily for 
categorical convenience. 

2.4. 15 System Administrator 

The SDR system administrator manages the master data store, POST control store, and POST master 
schema. The system administrator also configures user permissions and accounts, manages CM controls, 
and performs data base maintenance. 

2.4.16 WDS 

Working Data Store. The WDS refers to the working copy of the data store on the POST Tools PC at the 
customer's site or office PC at the home site. Here is where the customer, POST Field Engineer, or 
mission operator makes changes to the data units for a particular payload. The WDS acquires data units by 
checking them out from the payload CDS, and returns products upon completion by checking them back 
into the payload CDS. There may be more than one WDS in use at any time. 

2.5 MCC Display Tool 

This section contains the terms and definitions specific to the MCC Display Tool (MDT) product. 



2.4.10 
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2.5.1 ISP 

Information Sharing Protocol. The ISP is the distributed computing foundation for the mission control 
center. The ISP model includes both client-server and peer-to-peer relationships to distribute telemetry and 
computation data among differing owners and service providers. The ISP includes both data value and data 
status processing, although strictly speaking the data status processing is actually another protocol layer. 
ISP ships data on a change-only basis, and includes support for a variety of data types. Clients can also 
register as publishers of computed data, which the client sends back to its server for redistribution. The 
MCC baseline services include ISP servers for the MCC data acquisition data source, orbiter data reduction 
complex (ODRC) data files, a source-independent telemetry file (SITF) ASCII data source, and a null 
(repeater) data source. ISP servers also are available outside of the MCC baseline for other kinds of data 
sources. Because it is connection-oriented and layered onto TCP/IP, the ISP is transportable reliably across 
most networks. 



2.5.2 ISPresso 

ISPresso is a Java-language implementation of the ISP client library. This implementation is useful for 
Java clients (as applications, applets or servlets) to acquire real-time or playback telemetry from any ISP 
server. 

2.5.3 MSK Display 

Manual Select Keyboard Display. This term is a hold-over from the days when MCC mainframes 
generated the flight control console displays. MSK refers to one method for a console operator to select a 
numbered display and assign it to a console CRT. These real-time displays were largely non-graphical 
content with either a few values or a few hundred values contained therein. After installation of the console 
workstations programmers ported most of these display formats to the new platform, but the MSK moniker 
remained. 



2.5A PDB 

Portable Display Builder. The PDB is an internal USA Flight Operations product. The program container 
provides a friendly drag-and-drop graphical user interface for laying-out components on a display. The 
components typically are graphical objects from a library of typical real-time telemetry monitoring 
components such as digital values, meters, or plots. Among these components is a non-graphical ISPresso 
component that enables the displayed- value components to connect as a client to a remote ISP server. The 
program's container and its components are written in Java, so PDB is portable to a variety of platforms. 
We expect PDB to be the standard tool for the payload customer to use to build his real-time MCC 
telemetry monitoring displays. 

2.6 Orbiter-in-a-Box Tool 

This section contains the terms and definitions specific to the Orbiter-in-a-Box Tool product. 

2.6.1 Bus Model 

The GPC emulator software package includes a bus model. The bus model is an object class that captures 
the behavior of the many physical busses connected to a GPC. Instances of the class represent the 
instrumentation busses, inter-computer communication busses, mass memory busses, flight critical busses, 
display-keyboard busses, and so on. 



2.6.2 Checkpoint 

A checkpoint is a disk- stored snapshot of b flight software state. The PASS operator later can recall a 
checkpoint to initialize a GPC according to that software state. 
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2.6.3 Connectors 

This term refers to the physical modules (or ports) connecting two devices, in particular the connection 
between the payload and orbiter-in-a-box or the connection between the Cargo PC and the orbiter-in-a-box. 
The connector is either on the device or at the end of a cable connected to the device. 



2.6.4 Data Store 

A data store is similar to a checkpoint, except that a data store refers to the simulation model state. The 
orbiter-in-a-box can recover the model and flight software state from a data store. 

2.6.5 Delivery System 

The orbiter-in-a-box delivery system is the end-item product we loan to our POST customers. The USA 
Reconfiguration function and KSC cargo integration function also will have copies of the delivery system. 
The components of the delivery system have not yet been finalized, however it is likely to consist of: a 6- 
slot VMEbus backplane chassis with internal power supply and portable desktop enclosure; two dual- 
PowerPC 433 MHz processor cards; two 4416 telemetry cards; one 4422 telemetry card; and one PMC 
carrier board with two PMC host bus adapter daughter cards. 

2.6.6 Development System 

The orbiter-in-a-box development system is our first system and serves as our hardware and software 
development platform. The development system consists of: a 12-slot VMEbus backplane chassis with 
internal power supply; two dual-PowerPC 433 MHz processor cards (providing GPC functionality, SMS 
functionality and supporting services); two 4416 telemetry cards (one for PSP functionality, the other for 
PDI functionality); one 4422 telemetry card (for PCMMU functionality); one 1553 card (for OIU 
functionality); one Shuttle MDM card (for MDM firmware functionality); one industry pack mezzanine 
card with four discrete I/O daughter cards (for MDM I/O functionality); an Ethernet switch; one PMC 
carrier board with two PMC host bus adapter daughter cards (for Cargo PC interface and for a disk slot); 
and a VMEbus analyzer card. 

2.6.7 Disk Card 

This is a PCMCIA card providing a 1 GB hard disk. This disk contains the application software, 
reconfiguration files, and some of the system software necessary to initialize the orbiter-in-a-box. This 
card plugs into a PCMCIA slot in the orbiter-in-a-box. 

2.6.8 Ethernet Switch 

The orbiter-in-a-box development system enclosure contains a six-port 10/100 Base TX Ethernet switch. 
This switch provides a way to switch traffic from external systems and the two embedded processor boards 
without requiring an external switch. This is of interest primarily in standalone applications. 

2.6.9 Host Bus Adapter 

Certain of the orbiter-in-a-box boards contain PCI mezzanine card (PMC) slots for expansion capability. 
One board's purpose is simply to provide four PMC slots. The host bus adapters are PCI mezzanine cards 
that carry PCMCIA cards (converting from one bus type to another bus type). The PCMCIA cards provide 
disk storage, flash memory, network interfaces, MIL-STD-1553 interfaces, or Shuttle MDM serial I/O 
interfaces. 

2.6.10 ISP Server 

Information Sharing Protocol Server. The orbiter-in-a-box system software includes an ISP server (see 
2.5.1). This server acquires real-time data from the SMS model data pool and the PCMMU model. ISP 
client applications (elsewhere on the network) can request "telemetry" from this server to drive MCC-style 
displays and computations. 
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2.6.11 MCDS 

Multifunction CRT Display System. On-board the orbiter this refers to the CRT displays, keyboards, and 
processors attached to the flight computers through the display electronics units (DEU) and display- 
keyboard busses. This provides the crew's user-interface to the PASS. In the orbiter-in-a-box context, the 
MCDS refers to a Java-language software package that provides emulation of the DEU and simulation of 
the keyboards, CRTs and relevant panel switches. The emulation of the DEU refers to the program's 
ability to encode an decode DEU instructions for rendering displays or processing keyboard input. This 
MCDS provides the user interface to the PASS running on the GPCE inside the orbiter-in-a-box. Because 
it is written in Java, the MCDS program can run anywhere on the network. 

2.6.12 MDM 

Multiplexer-Demultiplexer. A multiplexer converts parallel input into one serial output. A demultiplexer 
converts serial input into parallel output. An orbiter MDM is a black box that performs both functions, 
enabling a device on the serial I/O side (such as a GPC or PCMMU) to communicate with many sensors 
and effectors on the parallel I/O side. There are many types and instances of MDMs on the orbiter. Those 
of primary interest to POST are the Payload MDMs (there are two of these, PF1 and PF2), which contain a 
card that communicates with serial I/O devices. The Cargo PC will haye^specially-designed PCMCIA 
card that connects to this serial I/O card within the Payload MDM: this path enables the Cargo PC to 
communicate with the GPCs. Specifically, this communication path enables the Cargo PC system software 
to send and receive messages with the GPCF (GPC payload command filter) application running in the 
PASS. To support the customer's development of this Cargo PC software, therefore, the orbiter-in-a-box 
provides a similar serial channel interface. The orbiter-in-a-box side of the interface uses a complementary 
specially-designed PCMCIA card called the MIC. 

2.6.13 MIC 

MDM Interface Card. This is a specially-designed PCMCIA card that enables the Cargo PC to 
communicate with the orbiter payload MDM serial interface. The MIC plugs into the Cargo PC. A cable 
connects the MIC with a serial I/O port in the crew compartment. The orbiter-in-a-box uses a unique 
version of the MIC for its side of the connection. The difference between the Cargo PC MIC and the 
orbiter-in-a-box MIC is that the latter is able to act as bus commander of the serial interface. When used 
with the orbiter-in-a-box, a cable connects the Cargo PC MIC directly with orbiter-in-a-box MIC. 

2.6.14 MMU Image 

Mass Memory Unit image. This is a data file that contains among other things the binary images of the 
flight software for the GPCs. The data file resides on the orbiter MMU for access by on-board systems. 
The orbiter-in-a-box is able to use this same data file (previously stored on a hard disk) as its source of 
flight software and other information. 

2.6.15 OIU 

Orbiter Interface Unit. The OIU enables the orbiter to communicate with the International Space Station. 
Basically, the OIU is a black box that provides a MflL-STD-1553 interface from the external world to the 
orbiter. The orbiter-in-a-box development system contains a 1553 card to simulate the OIU; however, this 
functionality is not envisioned for the initial delivery systems. 

2.6.16 Panel Switches 

The orbiter-in-a-box MCDS provides a graphical simulation of certain orbiter cockpit panels. The MCDS 
provides the portions of panels containing switches relevant to MCDS and GPC (emulator) control, such as 
panels C2, 06 and R12L. The MCDS user controls the position of the switches using the mouse. 
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2.6.17 Patch Panel 

Another name for the Transition Panel. 



2.6.18 PCM 

Pulse Code Modulation. PCM is a standard communications technique for telemetering and other 
applications. For orbiter-in-a-box, the communication link from the PCMMU to the Cargo PC and the 
communication link from the attached pay load to the PDI are in PCM format. The communication contents 
vary according to predefined data formats. 

2.6.19 PCMMU 

Pulse Code Modulation Master Unit. The orbiter's PCMMU collects telemetry from three sources and 
creates a consolidated telemetry output stream for the network signal processor (NSP). The PCMMU 
collects downlist telemetry from the GPC's, payload telemetry from the PDI, and operational 
instrumentation (OI) telemetry from the 01 MDM's. In the orbiter-in-a-box context, the PCMMU is a 
telemetry card that creates data for (a) output to the Cargo PC, and (b) output to the ISP server, which 
serves as the ground site telemetry distribution server. 

2.6.20 PDI 

Payload Data Interleaves The orbiter's PDI collects data input directly from the attached payloads and 
indirectly from the detached payloads (via the PSP). It multiplexes this input into a payload telemetry 
stream for the PCMMU. In the orbiter-in-a-box context, the PDI is a telemetry card that receives telemetry 
data from the attached payload (or test equipment). 

2.6.21 Processor Card 

The Orbiter-in-a-Box chassis requires one or more processor cards to run the tool's software. Each 
processor card contains two processors (the development system uses the PowerPC 750), a 1 MB shared L2 
cache, a 512 MB shared RAM, a 9 MB flash memory, two serial ports, a 10/100BaseTX Ethernet port, and 
a SCSI port. Both processor cards boot the VxWorks™ operating system. The First processor card is the 
system controller card, managing initialization and operation of the entire orbiter-in-a-box system. 

2.6.22 PSK 

Phase Shift Keying. The PSP issues serial commands to the attached payloads using PSK modulation. The 
orbiter-in-a-box also will generate these commands for the payload (or test equipment) using PSK 
modulation from its PSP telemetry card. 

2.6.23 PSP 

Payload Signal Processor. The orbiter's PSP receives telemetry from detached payloads (via the payload 
interrogator) and forwards it to the PDI, and it receives commands from payload MDM's and forwards 
them either to the attached payloads (via the payload patch panel) or the detached payloads (via the payload 
interrogator). In the orbiter-in-a-box sense, the PSP is a telemetry card that forwards commands from the 
payload MDM model to the attached payload (or test equipment). 

2.6.24 SCRAMNet 

Shared Common Random Access Memory Network. This term refers to a Systran Inc. product for 
implementing a network-based reflective memory service between real-time computer systems. In the 
orbiter-in-a-box tool context the SCRAMNet™ VMEbus card provides the high-speed memory access 
necessary to support the payload training models running on the POST Tools PC. The POST Tools PC 
likewise has a SCRAMNet product, though the PC version is a PCI bus card. 
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2.6.25 Serial Port 

There are two senses for this phrase. (1) The Cargo PC communicates with the GPCF through a payload 
MDM serial port. These transactions include poll requests and responses as well as commands. This port 
is really one channel on a payload MDM serial I/O card. (2) The orbiter-in-a-box processor cards can use a 
serial port (RS-232) to communicate with an external host. Using this feature, the processor card can 
initialize itself at boot time from files residing on file systems external to the processor. 

2.6.26 SIO 

Serial Input / Output. This refers to the communication protocol between the Cargo PC and the payload 
MDM. 

2.6.27 SIP 

Standard interface panel. A SIP is located on each side of the cargo bay to provide interfaces for the 
SMCH, add-on black boxes, unique connector panels, structural support and clamps for cables and the 
payload active cooling kit. The orbiter-in-a-box does not provide a SIP for development and testing. 

2.6.28 SMCH . 

Standard Mixed-Cargo Harness. This is the harness of electrical connections between the payload and the 
SIP. 

2.6.29 SSP 

Standard Switch Panel. These panels on the orbiter's aft flight desk are part of the crew's standard payload 
display and control interfaces. Each SSP can manage up to four payloads per mission, depending on 
payload requirements. 

2.6.30 SMS Models 

Shuttle Mission Simulator models. The orbiter-in-a-box application software includes a complete set of the 
SMS vehicle and environment models. These models previously were integrated with the GPC emulator, 
MDM models, PCMMU model and ISP server during the next-generation flight controller trainer 
development project. The orbiter-in-a-box supports this integrated model set in order to (a) generate 
simulated orbiter subsystem data streams for output to the Cargo PC, (b) test the integration of the 
customer's payload training model, and (c) generate a complete telemetry stream for an ISP server to test 
ground support client applications. 

2.6.31 Transition Panel 

The transition panel is a hardware device that converts one type of cabling and connectors to another type 
of cabling and connectors. Specifically, the transition panel will convert from the orbiter-in-a-box 
peripheral card commercial standard connectors to (a) Cargo PC connectors, and (b) orbiter payload 
connectors. 

2.6.32 VMEbus 

Versa-Module Eurocard bus. This is an international standard 32-bit backplane bus specification for 
embedded systems. The orbiter-in-a-box uses the VMEbus backplane for communication between the 
various processor and peripheral cards. The orbiter-in-a-box uses a backplane that supports cards of 6U 
size (height) and using the VMEbus standard PI and P2 connectors to support 32-bit data and 32-bit 
addresses. The orbiter-in-a-box does not use or need 64-bit VMEbus extensions. 
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2.6.33 VxWorks 

VxWorks™ is the name of the real-time operating system product we use for the orbiter-in-a-box 
processors running the GPC emulators, SMS models, and other application software components. 
VxWorks is the "target" side of the Tornado™ software development environment. 



2.6.34 Webserver 

The orbiter-in-a-box processor system software includes an embedded web (hypertext transfer protocol) 
server in the form of the WindWeb™ product. This enables network users with web browsers to post 
requests to the web server for system software control, debug information, and status updates. 

2.7 SMS Model Tool 

This section contains the terms and definitions specific to the SMS Model Tool product. 

2. 7. 1 Malfunctions 

In the SMS model tool context, the term malfunctions applies to the payload customer's model. The 
payload customer will create a payload model that is able to simulate alternative payload behaviors given 
an assertion of one or more likely payload faults (malfunctions). The consequences of these malfunctions 
appear in the model's performance signatures to the astronaut crew or flight control team. The payload 
model user interface will enable an instructor to assert or retract malfunctions. The user interface will 
provide a list of malfunctions that the model supports. 

2.7.2 Payload Model 

In the SMS model tool context a payload model refers to a software model of a payload's behavior for use 
in astronaut and flight control team training applications. Such a model generally synthesizes normal 
behaviors and abnormal behaviors (malfunctions) given configuration settings managed by an instructor. 
The controls and status feedback appear on an instructor display. Output (telemetry) from the model goes 
into the data pool for distribution to other applications. 

2.7.3 Payload Model Server 

The payload model server is an arbitrator for the payload model software. The payload models will run on 
PC's that communicate with the model server via reflective memory. The model server will provide 
pointers to orbiter subsystem and environment data that the payload model needs for input. Payload model 
output will go back to the payload model server via SCRAMNet™ (see 2.6.24) for distribution to 
simulation users. The payload model server is part of the SMS facility. 

2.7.4 SMS 

Shuttle Mission Simulator. The SMS is a high-fidelity Space Shuttle mission training facility located in 
Building 5 at JSC. The SMS uses real GPC's and an SMS-specific version of the flight software. 
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